-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a base multi-arch container image build and GH Actions #351
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! I'm loving that we can build the ARM64 images through Actions, too.
file: ./infrastructure/base-container-img | ||
platforms: linux/amd64,linux/arm64 | ||
tags: | | ||
riscvintl/udb:${{ github.sha }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The file bin/.container_tag
has the current version of the container. It's supposed to increment whenever the container changes. Can we use that as the tag instead of the commit SHA?
rm -rf /var/lib/apt/lists/* | ||
|
||
# Copy and install Ruby dependencies | ||
COPY Gemfile Gemfile.lock ./ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We've been installing the Ruby/Node/Python packages on the host (under ${UDB_ROOT}/.home/.gems
, ${UDB_ROOT}/node_modules
, and ${UDB_ROOT}/.home/.venv
, respectively). We then make sure that the UDB_ROOT is bound in the container. The thought was that it would (a) keep the container smaller, and (b) make it easier to add packages as we go (most additions won't need a container rebuild). You can see how all this gets set up in bin/setup
(which is implicitly called any time you execute a program under bin/
or the top-level do
script).
Is there a reason that we should be including them in the container instead?
on: | ||
schedule: | ||
# This will run every week at 00:00 UTC on Monday | ||
- cron: "0 0 * * 1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See comment on tag/packages: if we stick with the current scheme, we only need to build this when bin/.container_tag
changes.
feat: Add base container image and GitHub Actions workflow